home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Language/OS - Multiplatform Resource Library
/
LANGUAGE OS.iso
/
lisp
/
wgdb-42.lha
/
wgdb-4.2
/
gdb
/
gdb.info-6
< prev
next >
Wrap
Text File
|
1992-09-11
|
50KB
|
1,176 lines
Info file gdb.info, produced by Makeinfo, -*- Text -*- from input
file gdb-all.texi.
This file documents the GNU debugger GDB.
Copyright (C) 1988, 1989, 1990, 1991 Free Software Foundation, Inc.
Permission is granted to make and distribute verbatim copies of
this
manual provided the copyright notice and this permission notice are
preserved on all copies.
Permission is granted to copy and distribute modified versions of
this
manual under the conditions for verbatim copying, provided also that
the section entitled "GNU General Public License" is included
exactly as in the original, and provided that the entire resulting
derived work is distributed under the terms of a permission notice
identical to this one.
Permission is granted to copy and distribute translations of this
manual into another language, under the above conditions for
modified versions, except that the section entitled "GNU General
Public License" may be included in a translation approved by the
Free Software Foundation instead of in the original English.
File: gdb.info, Node: Emacs, Next: GDB Bugs, Prev: Sequences, Up: Top
Using GDB under GNU Emacs
*************************
A special interface allows you to use GNU Emacs to view (and edit)
the source files for the program you are debugging with GDB.
To use this interface, use the command `M-x gdb' in Emacs. Give
the executable file you want to debug as an argument. This command
starts GDB as a subprocess of Emacs, with input and output through a
newly created Emacs buffer.
Using GDB under Emacs is just like using GDB normally except for
two things:
* All "terminal" input and output goes through the Emacs buffer.
This applies both to GDB commands and their output, and to the
input and output done by the program you are debugging.
This is useful because it means that you can copy the text of
previous commands and input them again; you can even use parts of
the
output in this way.
All the facilities of Emacs' Shell mode are available for
interacting with your program. In particular, you can send signals
the usual way--for example, `C-c C-c' for an interrupt, `C-c C-z'
for a stop.
* GDB displays source code through Emacs.
Each time GDB displays a stack frame, Emacs automatically finds
the source file for that frame and puts an arrow (`=>') at the left
margin of the current line. Emacs uses a separate buffer for source
display, and splits the window to show both your GDB session and the
source.
Explicit GDB `list' or search commands still produce output as
usual, but you probably will have no reason to use them.
*Warning:* If the directory where your program resides is not
your current directory, it can be easy to confuse Emacs about
the location of the source files, in which case the auxiliary
display buffer will not appear to show your source. GDB can
find programs by searching your environment's `PATH' variable,
so the GDB input and output session will proceed normally; but
Emacs doesn't get enough information back from GDB to locate
the source files in this situation. To avoid this problem,
either start GDB mode from the directory where your program
resides, or specify a full path name when prompted for the `M-x
gdb' argument.
A similar confusion can result if you use the GDB `file' command
to switch to debugging a program in some other location, from
an existing GDB buffer in Emacs.
By default, `M-x gdb' calls the program called `gdb'. If you need
to call GDB by a different name (for example, if you keep several
configurations around, with different names) you can set the Emacs
variable `gdb-command-name'; for example,
(setq gdb-command-name "mygdb")
(preceded by `ESC ESC', or typed in the `*scratch*' buffer, or in
your `.emacs' file) will make Emacs call the program named "`mygdb'"
instead.
In the GDB I/O buffer, you can use these special Emacs commands in
addition to the standard Shell mode commands:
`C-h m'
Describe the features of Emacs' GDB Mode.
`M-s'
Execute to another source line, like the GDB `step' command;
also update the display window to show the current file and
location.
`M-n'
Execute to next source line in this function, skipping all
function calls, like the GDB `next' command. Then update the
display window to show the current file and location.
`M-i'
Execute one instruction, like the GDB `stepi' command; update
display window accordingly.
`M-x gdb-nexti'
Execute to next instruction, using the GDB `nexti' command;
update display window accordingly.
`C-c C-f'
Execute until exit from the selected stack frame, like the GDB
`finish' command.
`M-c'
Continue execution of the program, like the GDB `continue'
command. *Warning:* In Emacs v19, this command is `C-c C-p'.
`M-u'
Go up the number of frames indicated by the numeric argument
(*note Numeric Arguments: (emacs)Arguments.), like the GDB `up'
command. *Warning:* In Emacs v19, this command is `C-c C-u'.
`M-d'
Go down the number of frames indicated by the numeric argument,
like the GDB `down' command. *Warning:* In Emacs v19, this
command is `C-c C-d'.
`C-x &'
Read the number where the cursor is positioned, and insert it at
the end of the GDB I/O buffer. For example, if you wish to
disassemble code around an address that was displayed earlier,
type `disassemble'; then move the cursor to the address
display, and pick up the argument for `disassemble' by typing
`C-x &'.
You can customize this further on the fly by defining elements
of the list `gdb-print-command'; once it is defined, you can
format or otherwise process numbers picked up by `C-x &' before
they are inserted. A numeric argument to `C-x &' will both
indicate that you wish special formatting, and act as an index
to pick an element of the list. If the list element is a
string, the number to be inserted is formatted using the Emacs
function `format'; otherwise the number is passed as an
argument to the corresponding list element.
In any source file, the Emacs command `C-x SPC' (`gdb-break')
tells GDB to set a breakpoint on the source line point is on.
If you accidentally delete the source-display buffer, an easy way
to get it back is to type the command `f' in the GDB buffer, to
request a frame display; when you run under Emacs, this will
recreate the source buffer if necessary to show you the context of
the current frame.
The source files displayed in Emacs are in ordinary Emacs buffers
which are visiting the source files in the usual way. You can edit
the files with these buffers if you wish; but keep in mind that GDB
communicates with Emacs in terms of line numbers. If you add or
delete lines from the text, the line numbers that GDB knows will
cease to correspond properly to the code.
File: gdb.info, Node: GDB Bugs, Next: Renamed Commands, Prev: Emacs, Up: Top
Reporting Bugs in GDB
*********************
Your bug reports play an essential role in making GDB reliable.
Reporting a bug may help you by bringing a solution to your
problem, or it may not. But in any case the principal function of a
bug report is to help the entire community by making the next
version of GDB work better. Bug reports are your contribution to
the maintenance of GDB.
In order for a bug report to serve its purpose, you must include
the information that enables us to fix the bug.
* Menu:
* Bug Criteria:: Have You Found a Bug?
* Bug Reporting:: How to Report Bugs
File: gdb.info, Node: Bug Criteria, Next: Bug Reporting, Prev: GDB Bugs, Up: GDB Bugs
Have You Found a Bug?
=====================
If you are not sure whether you have found a bug, here are some
guidelines:
* If the debugger gets a fatal signal, for any input whatever,
that is a GDB bug. Reliable debuggers never crash.
* If GDB produces an error message for valid input, that is a bug.
* If GDB does not produce an error message for invalid input, that
is a bug. However, you should note that your idea of "invalid
input" might be our idea of "an extension" or "support for
traditional practice".
* If you are an experienced user of debugging tools, your
suggestions for improvement of GDB are welcome in any case.
File: gdb.info, Node: Bug Reporting, Prev: Bug Criteria, Up: GDB Bugs
How to Report Bugs
==================
A number of companies and individuals offer support for GNU
products. If you obtained GDB from a support organization, we
recommend you contact that organization first.
Contact information for many support companies and individuals is
available in the file `etc/SERVICE' in the GNU Emacs distribution.
In any event, we also recommend that you send bug reports for GDB
to one of these addresses:
bug-gdb@prep.ai.mit.edu
{ucbvax|mit-eddie|uunet}!prep.ai.mit.edu!bug-gdb
*Do not send bug reports to `info-gdb', or to `help-gdb', or to
any newsgroups.* Most users of GDB do not want to receive bug
reports. Those that do, have arranged to receive `bug-gdb'.
The mailing list `bug-gdb' has a newsgroup `gnu.gdb.bug' which
serves as a repeater. The mailing list and the newsgroup carry
exactly the same messages. Often people think of posting bug
reports to the newsgroup instead of mailing them. This appears to
work, but it has one problem which can be crucial: a newsgroup
posting often lacks a mail path back to the sender. Thus, if we
need to ask for more information, we may be unable to reach you.
For this reason, it is better to send bug reports to the mailing list.
As a last resort, send bug reports on paper to:
GNU Debugger Bugs
Free Software Foundation
545 Tech Square
Cambridge, MA 02139
The fundamental principle of reporting bugs usefully is this:
*report all the facts*. If you are not sure whether to state a fact
or leave it out, state it!
Often people omit facts because they think they know what causes
the problem and assume that some details don't matter. Thus, you
might assume that the name of the variable you use in an example
does not matter. Well, probably it doesn't, but one cannot be sure.
Perhaps the bug is a stray memory reference which happens to fetch
from the location where that name is stored in memory; perhaps, if
the name were different, the contents of that location would fool
the debugger into doing the right thing despite the bug. Play it
safe and give a specific, complete example. That is the easiest
thing for you to do, and the most helpful.
Keep in mind that the purpose of a bug report is to enable us to
fix the bug if it is new to us. It isn't as important what happens
if the bug is already known. Therefore, always write your bug
reports on the assumption that the bug has not been reported
previously.
Sometimes people give a few sketchy facts and ask, "Does this ring
a bell?" Those bug reports are useless, and we urge everyone to
*refuse to respond to them* except to chide the sender to report
bugs properly.
To enable us to fix the bug, you should include all these things:
* The version of GDB. GDB announces it if you start with no
arguments; you can also print it at any time using `show
version'.
Without this, we won't know whether there is any point in
looking for the bug in the current version of GDB.
* A complete input script, and all necessary source files, that
will reproduce the bug.
* What compiler (and its version) was used to compile GDB--e.g.
"gcc-1.37.1".
* The command arguments you gave the compiler to compile your
example and observe the bug. For example, did you use `-O'?
To
guarantee you won't omit something important, list them all.
If we were to try to guess the arguments, we would probably
guess wrong and then we might not encounter the bug.
* The type of machine you are using, and the operating system name
and version number.
* A description of what behavior you observe that you believe is
incorrect. For example, "It gets a fatal signal."
Of course, if the bug is that GDB gets a fatal signal, then we
will certainly notice it. But if the bug is incorrect output,
we might not notice unless it is glaringly wrong. We are
human, after all. You might as well not give us a chance to
make a mistake.
Even if the problem you experience is a fatal signal, you should
still say so explicitly. Suppose something strange is going
on, such as, your copy of GDB is out of synch, or you have
encountered a bug in the C library on your system. (This has
happened!) Your copy might crash and ours would not. If you
told us to expect a crash, then when ours fails to crash, we
would know that the bug was not happening for us. If you had
not told us to expect a crash, then we would not be able to
draw any conclusion from our observations.
* If you wish to suggest changes to the GDB source, send us
context diffs. If you even discuss something in the GDB
source, refer to it by context, not by line number.
The line numbers in our development sources won't match those in
your sources. Your line numbers would convey no useful
information to us.
Here are some things that are not necessary:
* A description of the envelope of the bug.
Often people who encounter a bug spend a lot of time
investigating which changes to the input file will make the bug
go away and which changes will not affect it.
This is often time consuming and not very useful, because the
way we will find the bug is by running a single example under
the debugger with breakpoints, not by pure deduction from a
series of examples. We recommend that you save your time for
something else.
Of course, if you can find a simpler example to report *instead*
of the original one, that is a convenience for us. Errors in
the output will be easier to spot, running under the debugger
will take less time, etc.
However, simplification is not vital; if you don't want to do
this, report the bug anyway and send us the entire test case
you used.
* A patch for the bug.
A patch for the bug does help us if it is a good one. But don't
omit the necessary information, such as the test case, on the
assumption that a patch is all we need. We might see problems
with your patch and decide to fix the problem another way, or
we might not understand it at all.
Sometimes with a program as complicated as GDB it is very hard
to construct an example that will make the program follow a
certain path through the code. If you don't send us the
example, we won't be able to construct one, so we won't be able
to verify that the bug is fixed.
And if we can't understand what bug you are trying to fix, or
why your patch should be an improvement, we won't install it.
A test case will help us to understand.
* A guess about what the bug is or what it depends on.
Such guesses are usually wrong. Even we can't guess right about
such things without first using the debugger to find the facts.
File: gdb.info, Node: Renamed Commands, Next: Installing GDB, Prev: GDB Bugs, Up: Top
Renamed Commands
****************
The following commands were renamed in GDB 4.0, in order to make
the command set as a whole more consistent and easier to use and
remember:
OLD COMMAND NEW COMMAND
--------------- -------------------------------
add-syms add-symbol-file
delete environment unset environment
info convenience show convenience
info copying show copying
info directories show directories
info editing show commands
info history show values
info targets help target
info values show values
info version show version
info warranty show warranty
set/show addressprint set/show print address
set/show array-max set/show print elements
set/show arrayprint set/show print array
set/show asm-demangle set/show print asm-demangle
set/show caution set/show confirm
set/show demangle set/show print demangle
set/show history write set/show history save
set/show prettyprint set/show print pretty
set/show screen-height set/show height
set/show screen-width set/show width
set/show sevenbit-strings set/show print sevenbit-strings
set/show unionprint set/show print union
set/show vtblprint set/show print vtbl
unset [No longer an alias for delete]
File: gdb.info, Node: Installing GDB, Next: Copying, Prev: Renamed Commands, Up: Top
Installing GDB
**************
GDB comes with a `configure' script that automates the process of
preparing GDB for installation; you can then use `make' to build the
`gdb' program.
The gdb distribution includes all the source code you need for gdb
in a single directory `gdb-4.2'. That directory in turn contains:
`gdb-4.2/configure (and supporting files)'
script for configuring GDB and all its supporting libraries.
`gdb-4.2/gdb'
the source specific to GDB itself
`gdb-4.2/bfd'
source for the Binary File Descriptor Library
`gdb-4.2/include'
GNU include files
`gdb-4.2/libiberty'
source for the `-liberty' free software library
`gdb-4.2/readline'
source for the GNU command-line interface
It is most convenient to run `configure' from the `gdb-4.2'
directory. The simplest way to configure and build GDB is the
following:
cd gdb-4.2
./configure HOST
make
where HOST is something like `sun4' or `decstation', that identifies
the platform where GDB will run. This builds the three libraries
`bfd', `readline', and `libiberty', then `gdb' itself. The
configured source files, and the binaries, are left in the
corresponding source directories.
`configure' is a Bourne-shell (`/bin/sh') script; if your system
doesn't recognize this automatically when you run a different shell,
you may need to run `sh' on it explicitly: `sh configure HOST'.
You can *run* the `configure' script from any of the subordinate
directories in the GDB distribution (if you only want to configure
that subdirectory); but be sure to specify a path to it. For
example, to configure only the `bfd' subdirectory,
cd gdb-4.2/bfd
../configure HOST
You can install `gdb' anywhere; it has no hardwired paths.
However, you should make sure that the shell on your path (named by
the `SHELL' environment variable) is publicly readable; some systems
refuse to let GDB debug child processes whose programs are not
readable, and GDB uses the shell to start your program.
* Menu:
* Subdirectories:: Configuration subdirectories
* Config Names:: Specifying names for hosts and targets
* configure Options:: Summary of options for configure
* Formatting Documentation:: How to format and print GDB documentation
File: gdb.info, Node: Subdirectories, Next: Config Names, Prev: Installing GDB, Up: Installing GDB
Configuration Subdirectories
============================
If you want to run GDB versions for several host or target
machines, you'll need a different gdb compiled for each combination
of host and target. `configure' is designed to make this easy by
allowing you to generate each configuration in a separate
subdirectory. If your `make' program handles the `VPATH' feature
(GNU `make' does), running `make' in each of these directories then
builds the gdb program specified there.
`configure' creates these subdirectories for you when you
simultaneously specify several configurations; but it's a good habit
even for a single configuration. You can specify the use of
subdirectories using the `+subdirs' option (abbreviated `+sub').
For example, you can build GDB this way on a Sun 4 as follows:
cd gdb-4.2
./configure +sub sun4
cd H-sun4/T-sun4
make
When `configure' uses subdirectories to build programs or
libraries, it creates nested directories `H-HOST/T-TARGET'.
`configure' uses these two directory levels because GDB can be
configured for cross-compiling: GDB can run on one machine (the
host) while debugging programs that run on another machine (the
target).
You specify cross-debugging targets by giving the `+target=TARGET'
option to `configure'. Specifying only hosts still gives you two
levels of subdirectory for each host, with the same configuration
suffix on both; that is, if you give any number of hosts but no
targets, GDB will be configured for native debugging on each host.
On the other hand, whenever you specify both hosts and targets on
the same command line, `configure' creates all combinations of the
hosts and targets you list.
If you run `configure' from a directory (notably, `gdb-4.2') that
contains source directories for multiple libraries or programs,
`configure' creates the `H-HOST/T-TARGET' subdirectories in each
library or program's source directory. For example, typing:
cd gdb-4.2
configure sun4 +target=vxworks960
creates the following directories:
gdb-4.2/H-sun4/T-vxworks960
gdb-4.2/bfd/H-sun4/T-vxworks960
gdb-4.2/gdb/H-sun4/T-vxworks960
gdb-4.2/libiberty/H-sun4/T-vxworks960
gdb-4.2/readline/H-sun4/T-vxworks960
When you run `make' to build a program or library, you must run it
in a configured directory. If you made a single configuration,
without subdirectories, run `make' in the source directory. If you
have `H-HOST/T-TARGET' subdirectories, run `make' in those
subdirectories.
The `Makefile' generated by `configure' for each source directory
runs recursively, so that typing `make' in `gdb-4.2' (or in a
`gdb-4.2/H-HOST/T-TARGET' subdirectory) builds all the required
libraries,
then GDB.
When you have multiple hosts or targets configured, you can run
`make' on them in parallel (for example, if they are NFS-mounted on
each of the hosts); they will not interfere with each other.
You can also use the `+objdir=ALTROOT' option to have the
configured files placed in a parallel directory structure rather
than alongside the source files; *note configure Options::..
File: gdb.info, Node: Config Names, Next: configure Options, Prev: Subdirectories, Up: Installing GDB
Specifying Names for Hosts and Targets
======================================
The specifications used for hosts and targets in the `configure'
script are based on a three-part naming scheme, but some short
predefined aliases are also supported. The full naming scheme
encodes three pieces of information in the following pattern:
ARCHITECTURE-VENDOR-OS
For example, you can use the alias `sun4' as a HOST argument or in
a `+target=TARGET' option, but the equivalent full name is
`sparc-sun-sunos4'.
The following table shows all the architectures, hosts, and OS
prefixes that `configure' recognizes in GDB 4.2. Entries in the "OS
prefix" column ending in a `*' may be followed by a release number.
ARCHITECTURE VENDOR OS prefix
------------+------------+-------------
| |
580 | altos | aix*
a29k | amd | amigados
alliant | amdahl | aout
arm | aout | bout
c1 | apollo | bsd*
c2 | att | coff
cray2 | bcs | ctix*
h8300 | bout | dgux*
i386 | bull | dynix*
i860 | cbm | ebmon
i960 | coff | esix*
m68000 | convergent | hds
m68k | convex | hpux*
m88k | cray | irix*
mips | dec | isc*
ns32k | encore | kern
pyramid | gould | mach*
romp | hitachi | msdos*
rs6000 | hp | newsos*
sparc | ibm | nindy*
tahoe | intel | osf*
tron | isi | sco*
vax | little | sunos*
xmp | mips | svr4
ymp | motorola | sym*
| ncr | sysv*
| next | ultrix*
| nyu | unicos*
| sco | unos*
| sequent | uts
| sgi | v88r*
| sony | vms*
| sun | vxworks*
| unicom |
| utek |
| wrs |
*Warning:* Many combinations of architecture, vendor, and OS are
untested.
The `configure' script accompanying GDB 4.2 does not provide any
query facility to list all supported host and target names or
aliases. `configure' calls the Bourne shell script `config.sub' to
map abbreviations to full names; you can read the script, if you
wish, or you can use it to test your guesses on abbreviations--for
example:
% sh config.sub sun4
sparc-sun-sunos4
% sh config.sub sun3
m68k-sun-sunos4
% sh config.sub decstation
mips-dec-ultrix
% sh config.sub hp300bsd
m68k-hp-bsd
% sh config.sub i386v
i386-none-sysv
% sh config.sub i486v
*** Configuration "i486v" not recognized
`config.sub' is also distributed in the directory `gdb-4.2'.
File: gdb.info, Node: configure Options, Next: Formatting Documentation, Prev: Config Names, Up: Installing GDB
`configure' Options
===================
Here is a summary of all the `configure' options and arguments
that you might use for building GDB:
configure [+destdir=DIR] [+subdirs]
[+objdir=ALTROOT] [+norecursion] [+rm]
[+target=TARGET...] HOST...
You may introduce options with the character `-' rather than `+' if
you prefer; but you may abbreviate option names if you use `+'.
`+destdir=DIR'
DIR is an installation directory *path prefix*. After you
configure with this option, `make install' will install GDB as
`DIR/bin/gdb', and the libraries in `DIR/lib'. If you specify
`+destdir=/usr/local', for example, `make install' creates
`/usr/local/bin/gdb'.
`+subdirs'
Write configuration specific files in subdirectories of the form
H-HOST/T-TARGET
(and configure the `Makefile' to generate object code in
subdirectories of this form as well). Without this option, if
you specify only one configuration for GDB, `configure' will
use the same directory for source, configured files, and
binaries. This option is used automatically if you specify
more than one HOST or more than one `+target=TARGET' option on
the `configure' command line.
`+norecursion'
Configure only the directory where `configure' is executed; do
not propagate configuration to subdirectories.
`+objdir=ALTROOT'
ALTROOT is an alternative directory used as the root for
configured files. `configure' will create directories under
ALTROOT in parallel to the source directories. If you use
`+objdir=ALTROOT' with `+subdirs', `configure' also builds the
`H-HOST/T-TARGET' subdirectories in the directory tree rooted
in ALTROOT.
`+rm'
Remove the configuration that the other arguments specify.
`+target=TARGET ...'
Configure GDB for cross-debugging programs running on each
specified TARGET. You may specify as many `+target' options as
you wish. Without this option, GDB is configured to debug
programs that run on the same machine (HOST) as GDB itself.
There is no convenient way to generate a list of all available
targets.
`HOST ...'
Configure GDB to run on each specified HOST. You may specify as
many host names as you wish.
There is no convenient way to generate a list of all available
hosts.
`configure' accepts other options, for compatibility with configuring
other GNU tools recursively; but these are the only options that
affect GDB or its supporting libraries.
File: gdb.info, Node: Formatting Documentation, Prev: configure Options, Up: Installing GDB
Formatting the Documentation
============================
The GDB 4.2 release includes an already-formatted reference card,
ready for printing on a PostScript printer, as
`gdb-4.2/gdb/refcard.ps'. It uses the most common PostScript fonts:
the Times family, Courier, and Symbol. If you have a PostScript
printer, you can print the reference card by just sending
`refcard.ps' to the printer.
The release also includes the online Info version of this manual
already formatted: the main Info file is `gdb-4.2/gdb/gdb.info', and
it refers to subordinate files matching `gdb.info*' in the same
directory.
If you want to make these Info files yourself from the GDB
manual's source, you need the GNU `makeinfo' program. Once you have
it, you can type
cd gdb-4.2/gdb
make gdb.info
to make the Info file.
If you want to format and print copies of the manual, you need
several things:
* TeX, the public domain typesetting program written by Donald
Knuth, must be installed on your system and available through
your execution path.
* `gdb-4.2/texinfo': TeX macros defining the GNU Documentation
Format.
* *A DVI output program.* TeX doesn't actually make marks on
paper; it produces output files called DVI files. If your
system has TeX installed, chances are it has a program for
printing out these files; one popular example is `dvips', which
can print DVI files on PostScript printers.
Once you have these things, you can type
cd gdb-4.2/gdb
make gdb.dvi
to format the text of this manual, and print it with the usual output
method for TeX DVI files at your site.
If you want to print the reference card, but don't have a
PostScript printer, or you want to use Computer Modern fonts
instead, you can still print it if you have TeX. Format the
reference
card by typing
cd gdb-4.2/gdb
make refcard.dvi
The GDB reference card is designed to print in landscape mode on US
"letter" size paper; that is, on a sheet 11 inches wide by 8.5
inches high. You will need to specify this form of printing as an
option to your DVI output program.
File: gdb.info, Node: Copying, Next: Index, Prev: Installing GDB, Up: Top
GNU GENERAL PUBLIC LICENSE
**************************
Version 2, June 1991
Copyright (C) 1989, 1991 Free Software Foundation, Inc.
675 Mass Ave, Cambridge, MA 02139, USA
Everyone is permitted to copy and distribute verbatim copies
of this license document, but changing it is not allowed.
Preamble
========
The licenses for most software are designed to take away your
freedom to share and change it. By contrast, the GNU General Public
License is intended to guarantee your freedom to share and change
free software--to make sure the software is free for all its users.
This General Public License applies to most of the Free Software
Foundation's software and to any other program whose authors commit
to using it. (Some other Free Software Foundation software is
covered by the GNU Library General Public License instead.) You can
apply it to your programs, too.
When we speak of free software, we are referring to freedom, not
price. Our General Public Licenses are designed to make sure that
you have the freedom to distribute copies of free software (and
charge for this service if you wish), that you receive source code
or can get it if you want it, that you can change the software or
use pieces of it in new free programs; and that you know you can do
these things.
To protect your rights, we need to make restrictions that forbid
anyone to deny you these rights or to ask you to surrender the rights.
These restrictions translate to certain responsibilities for you if
you distribute copies of the software, or if you modify it.
For example, if you distribute copies of such a program, whether
gratis or for a fee, you must give the recipients all the rights
that
you have. You must make sure that they, too, receive or can get the
source code. And you must show them these terms so they know their
rights.
We protect your rights with two steps: (1) copyright the software,
and (2) offer you this license which gives you legal permission to
copy, distribute and/or modify the software.
Also, for each author's protection and ours, we want to make
certain that everyone understands that there is no warranty for this
free software. If the software is modified by someone else and
passed on, we want its recipients to know that what they have is not
the original, so that any problems introduced by others will not
reflect on the original authors' reputations.
Finally, any free program is threatened constantly by software
patents. We wish to avoid the danger that redistributors of a free
program will individually obtain patent licenses, in effect making
the program proprietary. To prevent this, we have made it clear
that any patent must be licensed for everyone's free use or not
licensed at all.
The precise terms and conditions for copying, distribution and
modification follow.
TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION
1. This License applies to any program or other work which contains
a notice placed by the copyright holder saying it may be
distributed under the terms of this General Public License.
The "Program", below, refers to any such program or work, and a
"work based on the Program" means either the Program or any
derivative work under copyright law: that is to say, a work
containing the Program or a portion of it, either verbatim or
with modifications and/or translated into another language.
(Hereinafter, translation is included without limitation in the
term "modification".) Each licensee is addressed as "you".
Activities other than copying, distribution and modification
are not covered by this License; they are outside its scope.
The act of running the Program is not restricted, and the
output from the Program is covered only if its contents
constitute a work based on the Program (independent of having
been made by running the Program). Whether that is true
depends on what the Program does.
2. You may copy and distribute verbatim copies of the Program's
source code as you receive it, in any medium, provided that you
conspicuously and appropriately publish on each copy an
appropriate copyright notice and disclaimer of warranty; keep
intact all the notices that refer to this License and to the
absence of any warranty; and give any other recipients of the
Program a copy of this License along with the Program.
You may charge a fee for the physical act of transferring a
copy, and you may at your option offer warranty protection in
exchange for a fee.
3. You may modify your copy or copies of the Program or any portion
of it, thus forming a work based on the Program, and copy and
distribute such modifications or work under the terms of
Section 1 above, provided that you also meet all of these
conditions:
a) You must cause the modified files to carry prominent
notices stating that you changed the files and the date of
any change.
b) You must cause any work that you distribute or publish,
that in whole or in part contains or is derived from the
Program or any part thereof, to be licensed as a whole at
no charge to all third parties under the terms of this
License.
c) If the modified program normally reads commands
interactively when run, you must cause it, when started
running for such interactive use in the most ordinary way,
to print or display an announcement including an
appropriate copyright notice and a notice that there is no
warranty (or else, saying that you provide a warranty) and
that users may redistribute the program under these
conditions, and telling the user how to view a copy of
this License. (Exception: if the Program itself is
interactive but does not normally print such an
announcement, your work based on the Program is not
required to print an announcement.)
These requirements apply to the modified work as a whole. If
identifiable sections of that work are not derived from the
Program, and can be reasonably considered independent and
separate works in themselves, then this License, and its terms,
do not apply to those sections when you distribute them as
separate works. But when you distribute the same sections as
part of a whole which is a work based on the Program, the
distribution of the whole must be on the terms of this License,
whose permissions for other licensees extend to the entire
whole, and thus to each and every part regardless of who wrote
it.
Thus, it is not the intent of this section to claim rights or
contest your rights to work written entirely by you; rather,
the intent is to exercise the right to control the distribution
of derivative or collective works based on the Program.
In addition, mere aggregation of another work not based on
the Program with the Program (or with a work based on the
Program) on a volume of a storage or distribution medium does
not bring the other work under the scope of this License.
4. You may copy and distribute the Program (or a work based on it,
under Section 2) in object code or executable form under the
terms of Sections 1 and 2 above provided that you also do one
of the following:
a) Accompany it with the complete corresponding
machine-readable source code, which must be distributed
under the terms of Sections 1 and 2 above on a medium
customarily used for software interchange; or,
b) Accompany it with a written offer, valid for at least three
years, to give any third party, for a charge no more than
your cost of physically performing source distribution, a
complete machine-readable copy of the corresponding source
code, to be distributed under the terms of Sections 1 and
2 above on a medium customarily used for software
interchange; or,
c) Accompany it with the information you received as to the
offer to distribute corresponding source code. (This
alternative is allowed only for noncommercial distribution
and only if you received the program in object code or
executable form with such an offer, in accord with
Subsection b above.)
The source code for a work means the preferred form of the
work for making modifications to it. For an executable work,
complete source code means all the source code for all modules
it contains, plus any associated interface definition files,
plus the scripts used to control compilation and installation
of the executable. However, as a special exception, the source
code distributed need not include anything that is normally
distributed (in either source or binary form) with the major
components (compiler, kernel, and so on) of the operating
system on which the executable runs, unless that component
itself accompanies the executable.
If distribution of executable or object code is made by
offering access to copy from a designated place, then offering
equivalent access to copy the source code from the same place
counts as distribution of the source code, even though third
parties are not compelled to copy the source along with the
object code.
5. You may not copy, modify, sublicense, or distribute the Program
except as expressly provided under this License. Any attempt
otherwise to copy, modify, sublicense or distribute the Program
is void, and will automatically terminate your rights under
this License. However, parties who have received copies, or
rights, from you under this License will not have their
licenses terminated so long as such parties remain in full
compliance.
6. You are not required to accept this License, since you have not
signed it. However, nothing else grants you permission to
modify or distribute the Program or its derivative works.
These actions are prohibited by law if you do not accept this
License. Therefore, by modifying or distributing the Program
(or any work based on the Program), you indicate your
acceptance of this License to do so, and all its terms and
conditions for copying, distributing or modifying the Program
or works based on it.
7. Each time you redistribute the Program (or any work based on the
Program), the recipient automatically receives a license from
the original licensor to copy, distribute or modify the Program
subject to these terms and conditions. You may not impose any
further restrictions on the recipients' exercise of the rights
granted herein. You are not responsible for enforcing
compliance by third parties to this License.
8. If, as a consequence of a court judgment or allegation of patent
infringement or for any other reason (not limited to patent
issues), conditions are imposed on you (whether by court order,
agreement or otherwise) that contradict the conditions of this
License, they do not excuse you from the conditions of this
License. If you cannot distribute so as to satisfy
simultaneously your obligations under this License and any
other pertinent obligations, then as a consequence you may not
distribute the Program at all. For example, if a patent
license would not permit royalty-free redistribution of the
Program by all those who receive copies directly or indirectly
through you, then the only way you could satisfy both it and
this License would be to refrain entirely from distribution of
the Program.
If any portion of this section is held invalid or
unenforceable under any particular circumstance, the balance of
the section is intended to apply and the section as a whole is
intended to apply in other circumstances.
It is not the purpose of this section to induce you to
infringe any patents or other property right claims or to
contest validity of any such claims; this section has the sole
purpose of protecting the integrity of the free software
distribution system, which is implemented by public license
practices. Many people have made generous contributions to the
wide range of software distributed through that system in
reliance on consistent application of that system; it is up to
the author/donor to decide if he or she is willing to
distribute software through any other system and a licensee
cannot impose that choice.
This section is intended to make thoroughly clear what is
believed to be a consequence of the rest of this License.
9. If the distribution and/or use of the Program is restricted in
certain countries either by patents or by copyrighted
interfaces, the original copyright holder who places the
Program under this License may add an explicit geographical
distribution limitation excluding those countries, so that
distribution is permitted only in or among countries not thus
excluded. In such case, this License incorporates the
limitation as if written in the body of this License.
10. The Free Software Foundation may publish revised and/or new
versions of the General Public License from time to time. Such
new versions will be similar in spirit to the present version,
but may differ in detail to address new problems or concerns.
Each version is given a distinguishing version number. If
the Program specifies a version number of this License which
applies to it and "any later version", you have the option of
following the terms and conditions either of that version or of
any later version published by the Free Software Foundation.
If the Program does not specify a version number of this
License, you may choose any version ever published by the Free
Software Foundation.
11. If you wish to incorporate parts of the Program into other free
programs whose distribution conditions are different, write to
the author to ask for permission. For software which is
copyrighted by the Free Software Foundation, write to the Free
Software Foundation; we sometimes make exceptions for this.
Our decision will be guided by the two goals of preserving the
free status of all derivatives of our free software and of
promoting the sharing and reuse of software generally.
NO WARRANTY
12. BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO
WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE
LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT
HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM "AS IS"
WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED,
INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE
ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS
WITH YOU. SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE
COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION.
13. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN
WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY
MODIFY AND/OR REDISTRIBUTE THE PROGRAM AS PERMITTED ABOVE, BE
LIABLE TO YOU FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL,
INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR
INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED TO LOSS
OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED
BY YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE
WITH ANY OTHER PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY
HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
END OF TERMS AND CONDITIONS
Applying These Terms to Your New Programs
=========================================
If you develop a new program, and you want it to be of the
greatest possible use to the public, the best way to achieve this is
to make it free software which everyone can redistribute and change
under these terms.
To do so, attach the following notices to the program. It is
safest to attach them to the start of each source file to most
effectively convey the exclusion of warranty; and each file should
have
at least the "copyright" line and a pointer to where the full notice
is found.
ONE LINE TO GIVE THE PROGRAM'S NAME AND A BRIEF IDEA OF WHAT IT DOES.
Copyright (C) 19YY NAME OF AUTHOR
This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 2 of the License, or
(at your option) any later version.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along with this program; if not, write to the Free Software
Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
Also add information on how to contact you by electronic and paper
mail.
If the program is interactive, make it output a short notice like
this when it starts in an interactive mode:
Gnomovision version 69, Copyright (C) 19YY NAME OF AUTHOR
Gnomovision comes with ABSOLUTELY NO WARRANTY; for details type `show w'.
This is free software, and you are welcome to redistribute it
under certain conditions; type `show c' for details.
The hypothetical commands `show w' and `show c' should show the
appropriate parts of the General Public License. Of course, the
commands you use may be called something other than `show w' and
`show c'; they could even be mouse-clicks or menu items--whatever
suits
your
program.
You should also get your employer (if you work as a programmer) or
your school, if any, to sign a "copyright disclaimer" for the
program, if necessary. Here is a sample; alter the names:
Yoyodyne, Inc., hereby disclaims all copyright interest in the program
`Gnomovision' (which makes passes at compilers) written by James Hacker.
SIGNATURE OF TY COON, 1 April 1989
Ty Coon, President of Vice
This General Public License does not permit incorporating your
program into proprietary programs. If your program is a subroutine
library, you may consider it more useful to permit linking
proprietary applications with the library. If this is what you want
to do, use the GNU Library General Public License instead of this
License.